Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-braden-shared-media-00.txt < prev next >

Wrap

Text File | 1993-10-18 | 36KB | 941 lines

Internet Draft R. Braden Expires: April 1994 USC-ISI <draft-braden-shared-media-00.txt> Jon Postel USC-ISI Yakov Rekhter IBM Research October 1993 Internet Architecture Extensions for Shared Media Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Abstract The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption is violated for shared media, such as large public data networks. The architecture still works if this is violated, but some unnecessary host-router and router-router hops may result. This memo discusses alternative approaches to extension of the Internet architecture for efficient use of shared media. 1. INTRODUCTION This memo concerns the implications of shared medium networks for the architecture of the TCP/IP protocol suite. General familiarity with the TCP/IP architecture and the IP protocol is assumed. The Internet architecture is founded upon what was originally called the "Catenet model" [PSC81]. Under this model, the Internet (originally dubbed "the Catenet") is formed using routers (originally called "gateways") to interconnect distinct and perhaps diverse networks. An IP host address (more correctly characterized as a Braden, Postel, Rekhter Expires: April 1994 [Page 1] Internet Draft Shared Media IP Architecture October 1993 network interface address) is formed of the pair (net#,host#). Here "net#" is a unique IP number assigned to the network (or subnet) to which the host is attached, and "host#" identifies the host on that network (or subnet). The original Internet model made the implicit assumptions that each network has a single IP network number and that networks with different numbers may interchange packets only through routers. This assumption may be violated for networks implemented using a common "shared medium" (SM) at the link layer (LL). For example, in operational environments, network managers sometimes want to configure multiple IP network numbers (usually subnet numbers) on a single Ethernet. Potentially more important examples of shared media are provided by the proposed large (switched) public data networks (LPDNs). This memo concerns a set of changes that will provide the desired efficiency in an SM while retaining the coherence of the existing architecture. This issue has arisen in a number of IETF Working Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP for IP, and BGP. It is clearly time to take a careful look at the architectural issues to be solved. This memo first summarizes the relevant aspects of the original architecture (Section 2), and then it shows the effect of introducing shared media networks and the problems to be solved (Section 3). Then it discusses possible solutions (Section 4). 2. THE ORIGINAL ARCHITECTURE We very briefly review the original architecture, to introduce the terminology and concepts we need. Figure 1 illustrates a typical set of four networks A, ... D, represented traditionally as clouds, interconnected by routers R2, R3, and R4. Routers R1 and R5 connect to other parts of the Internet. Ha, It is not necessary to distinguish between network and subnet in this memo. We may assume that there is some address mask associated with each "network" in Figure 1, allowing a host or router to divide the 32 bits of an IP address into an address for the cloud and a host number that is defined uniquely only within that cloud. Braden, Postel, Rekhter Expires: April 1994 [Page 2] Internet Draft Shared Media IP Architecture October 1993 Ha Hb Hc Hd | | | | | | | | _|_ _|_ _|_ _|_ ( ) ( ) ( ) ( ) (Net) (Net) (Net) (Net) ( A ) ( B ) ( C ) ( D ) - R1 --( )-- R2 --( )-- R3 --( )-- R4 --( )-- R5 -- ( ) ( ) ( ) ( ) (___) (___) (___) (___) Figure 1. Example Internet Fragment An Internet router is connected to local network(s) as a special kind of host. Indeed, for network management purposes, a router plays the role of a host by originating and terminating datagrams. However, there is an important difference between a host and a router: the routing function is mostly centralized in the routers, allowing hosts to be "dumb" about routing. Internet hosts [RFC-1122] are required to make only one simple routing decision: is the destination address local to the connected network? If the address is not local, we say it is "foreign" (relative to the connected network). A host sends a datagram directly to a local destination address, or for a foreign destination, to a first-hop router. The host initially uses some "default" router for any new destination address. If the default is the wrong choice, that router returns a Redirect message and forwards the datagram. The Redirect message specifies the preferred first-hop router for the given destination address. The host uses this information, which it maintains in a "routing cache" [RFC-1122], to determine the first-hop address for subsequent datagrams to the same destination. To actually forward an IP datagram across a network hop, the sender must have the link layer (LL) address of the target. Therefore, each host and router must have some "address resolution" procedure to map IP address -> LL address. ARP, used for networks with broadcast capability, is the most common address resolution procedure [Plummer82]. If there is no LL broadcast capability (or if it is too expensive), then there are two other approaches to address resolution: local configuration tables, or some server that can be consulted using point-to-point transmission in the local medium. We will refer to the last as an "address-resolution server", or AR Server. Hosts would be configured with the LL address(es) of AR Server(s), while the servers would ultimately depend upon configured tables of LL address(es). Braden, Postel, Rekhter Expires: April 1994 [Page 3] Internet Draft Shared Media IP Architecture October 1993 The examples in this memo use ARP for address resolution. At least some of the LPDN's that are planned will provide sufficient broadcast capability to support ARP. It is important to note that ARP operates at the link layer, while the Redirect and routing cache mechanisms operate at the IP layer of the protocol stack. 3. THE PROBLEMS INTRODUCED BY SHARED MEDIA Figure 2 shows the same configuration as Figure 1, but now networks A, B, C, and D are all within the same shared medium (SM), shown by the dashed box enclosing the clouds. Networks A, ... D are now logical IP networks (called LIS's in [Laubach93]) rather than physical networks, and each of these logical networks may (or may not) be administratively distinct. The SM allows direct connectivity between any two hosts or routers connected to it. For example, host Ha can interchange datagrams directly with host Hd or with router R4. A router that has some but not all of its interfaces connected to the shared medium is called a "border router"; R5 is an example. Ha Hb Hc Hd | | | | ---- | ---------- | ---------- | ---------- | ---- | __|__ __|__ __|__ __|__ | ( ) ( ) ( ) ( ) | ( ) ( ) ( ) ( ) | ( Net ) ( Net ) ( Net ) ( Net ) | ( A ) ( B ) ( C ) ( D ) | ( ) ( ) ( ) ( ) | ( ) ( ) ( ) ( ) | (_____) (_____) (_____) ( ____) | | | | | | | | | | --- | | -------- | | -------- | | -------- | | --- | | | | | | | | - R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 --- Figure 2. Logical IP Networks in Shared Medium Figure 2 illustrates the "classical" model [Laubach93] for use of the Internet architecture within a shared medium, i.e., simply applying the original Internet architecture described earlier. This will provide correct but not optimal operation. For example, in the case of two hosts on the same logical network Braden, Postel, Rekhter Expires: April 1994 [Page 4] Internet Draft Shared Media IP Architecture October 1993 (not shown in Figure 2), the original rules will clearly work; the source host will forward a datagram directly in a single hop to a host on the same logical network. The original rules will also work for communication between any pair of hosts shown in Figure 2. However, the classical model does not take advantage of the direct connectivity allowed by the shared medium. Suppose host Ha wants to send a datagram to Hd; the original architecture will use the four-hop path Ha -> R2 -> R3 -> R4 -> Hd instead of the direct path Ha -> Hd. The extra hops may be desirable, as they allow the routers to act as administrative firewalls. On the other hand, when such firewall protection is not required, it should be possible to take advantage of the shared medium to allow this datagram to use shorter paths. In general, it should be possible to choose between firewall security and efficient connectivity. This memo concerns how to achieve minimal-hop connectivity when it is desired. Note that ARP requires LL broadcast. Even if the SM supports broadcast, it is likely that the administrators will erect firewalls to keep broadcasts local to their LIS. There are three cases to be optimized. Suppose H and H' are hosts and Rb and Rb' are border routers connected to the same same SM. Then the following one-hop paths should be possible: H -> H': Host to host within the SM H -> Rb: Host to exit router Rb -> Rb': Entry boder router to exit border router, for transit traffic. We may or not be able to remove the extra hop implicit in Rb -> R -> H, where the ultimate source is outside the SM. To remove this hop would require distribution of host routes, not just network routes, between the two routers R and Rb. There are a number of important requirements for any architectural solution to these problems. * Interoperability Modified hosts and routers must interoperate with unmodified nodes. Braden, Postel, Rekhter Expires: April 1994 [Page 5] Internet Draft Shared Media IP Architecture October 1993 * Practicality Minimal software changes should be required. * Robustness The new scheme must be robust against errors in software, configuration, or transmission. * Security The new scheme must be securable against subversion. The distinction between host and router is very significant from an engineering viewpoint. It is considered to be much harder to make a global change in host software than to change router software, because there are many more hosts and host vendors than routers and router vendors, and because hosts are less centrally administered than routers. If it is necessary to change the specification of what a host does (and it is), then we must minimize the extent of this change. 4. SOME SOLUTIONS TO THE SM PROBLEMS Four different approaches have been suggested for solving these SM problems. (1) Iterated Redirects In this approach, the host Redirect mechanism is extended to collapse multiple-hop paths within the same shared medium, hop- by-hop. A router will be allowed to send, and a host will be allowed to accept, a Redirect message that specifies a foreign IP address within the same SM. We refer to this as a "foreign Redirect". (2) Extended Routing Routing protocols can be modified to know about the SM and to provide LL addresses. (3) Extended Proxy ARP This is a form of the proxy ARP approach, in which the routing problem is solved implicitly by an extended address resolution mechanism at the LL. This approach has been described by Heinanen [Heinanen93] and by Garrett et al [Garratt93]. Braden, Postel, Rekhter Expires: April 1994 [Page 6] Internet Draft Shared Media IP Architecture October 1993 (4) Route Query Messages This approach has been suggested by Halpern [Halpern93]. Rather than adding additional information to routing, this approach would add a new IP-layer mechanism, end-to-end query and reply datagrams. These four are discussed in the following four subsections. 4.1 Hop-by-Hop Redirection The first scheme we consider would operate at the IP layer. It would cut out extra hops one by one, with each router in the path operating on local information only. This approach requires both host and router changes but no routing protocol changes. The basic idea is that the first-hop router, upon observing that the next hop is within the same SM, sends a foreign Redirect to the source, redirecting it to the next hop. Successive application of this algorithm at each intermediate router will eventually result in a direct path from source host to destination host, if both are within the same SM. Suppose that Ha wants to send a datagram to Hd. We use the notation IP.a for the IP address of entity a, and LL.a for the corresponding LL address. Each line in the following shows an IP datagram and the path that datagram will follow, separated by a colon. The notation "Redirect( h, IP.a)" means a Redirect specifying IP.a as the best next hop to reach host h. (1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd (2) Redirect(Hd, IP.R3): R2 -> Ha (3) Datagram 2: Ha -> R3 -> R4 -> Hd (4) Redirect(Hd, IP.R4): R3 -> Ha (5) Datagram 3: Ha -> R4 -> Hd (6) Redirect(Hd, IP.Hd): R4 -> Ha (7) Datagram 4: Ha -> Hd There are three problems to be solved to make this work. IR1: Each router must be able to resolve the LL address of the source Ha, to send a (foreign) Redirect. Braden, Postel, Rekhter Expires: April 1994 [Page 7] Internet Draft Shared Media IP Architecture October 1993 Let us assume that the link layer provides the source LL address when an IP datagram arrives. If the router determines that a Redirect should be sent, then it will be sent to the source LL address of the received datagram. IR2: A source host must be able to resolve the LL address of each router to which it is redirected. It would be possible for each router R, upon sending a Redirect to Ha, to also send an unsolicited ARP Reply point- to-point to LL.Ha, updating Ha's ARP cache with LL.R. However, there is not guarantee that this unsolicited ARP Reply would be delivered. If it was lost, there would be a forwarding black hole. The host could recover by starting over from the original default router; however, this may be too obtuse a solution. A much more direct solution would introduce an extended ICMP Redirect message (call it XRedirect) that carries the LL address as well as the IP address of the target. This removes the issue of reliable delivery of the unsolicited ARP described earlier, because the fate of the LL address is shared with the IP target address; both are delivered or neither are. Using XRedirect and omitting the spurious router-router XRedirects, the previous example becomes: (1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd (2) XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha (3) Datagram 2: Ha -> R3 -> R4 -> Hd (4) XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha (5) Datagram 3: Ha -> R4 -> Hd (6) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha (7) Datagram 4: Ha -> Hd IR3: Each router should be able to recognize when it is the first hop in the path, since a Redirect should be sent only by the first hop router. Unfortunately this is not generally possible, since a router in this chain determines the LL address of the source only from the arriving datagram, as indicated in IR1 above. Therefore, application of this Braden, Postel, Rekhter Expires: April 1994 [Page 8] Internet Draft Shared Media IP Architecture October 1993 technique by routers in the path after the first-hop router will cause them to send spurious [X]Redirects; these will be sent to the IP address of the source host, but using the LL address of the previous-hop router. These will be ignored by the routers and cause no harm. The Host Requirements RFC [RFC-1122] specifies the host mechanism for routing an outbound datagram in terms of sending the datagram either directly to a local destination or else to the first hop router to reach a foreign destination [RFC-1122 3.3.1]. However, if the routing cache did specify a foreign target address, the mechanism as described should forward the datagram directly to that foreign address, as we require for efficient SM operation. The target address contained in the routing cache is updated by Redirect messages. There is currently a restriction on what target addresses may be accepted in Redirect messages [RFC-1122 3.2.2.2]: A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination. The minimal change for SMs would remove the first validity check and generalize the second, as follows: A Redirect message SHOULD be silently discarded if the source of the Redirect is not the current target address in the routing cache for the specified destination. Thus, the new validation test is that a Redirect must come from the node to which we sent the datagram that triggered the Redirect. In order to send a datagram to the target address found in the routing cache, a host must resolve the IP address into a LL address. We assume that no change is necessary in the current IP->LL resolution mechanism in the host to handle a foreign rather than a local address. Thus, the only change required of a host is to remove one of the validity checks on a Redirect message. By design, the router changes required to improve SM efficiency are much more extensive than the host changes. The examples given earlier showed two kinds of additional router function. Braden, Postel, Rekhter Expires: April 1994 [Page 9] Internet Draft Shared Media IP Architecture October 1993 (1) Sending Foreign Redirects Consider a router that is connected to an SM. When it receives a datagram, it tests whether the next hop is on the same SM, and if so, it sends a foreign XRedirect to the source host, using the link layer address with which the datagram arrived. A router should avoid sending more than a limited number of successive foreign Redirects to the same host. This is necessary because an unmodified host may legitimately ignore a Redirect to a foreign network and continue to forward datagrams to the same router. A router can accomplish this limitation by keeping a cache of foreign Redirects sent. Note that foreign Redirects generated by routers according to these rules, like the current local Redirects, may travel exactly one link-layer hop. It is therefore reasonable and desirable to set their TTL to 1, to ensure they cannot stray outside the SM. (2) SM-wise Routing A modified routing protocol could allow a router to know which other routers are in the same SM, in order to forward a datagram directly to the last hop router within the SM. This is discussed in the following section. 4.2 Extended Routing The routing protocols may be modified to carry additional information that is specific to the SM. The router could use the attribute "SameSM" for a route to deduce the shortest path to be reported to its neighbors. It could also carry the LL addresses with each router IP address. For example, the modified routing protocol would allow R2 to know that R4 is the best next-hop to reach the destination network in the same SM, and to know both IP.R4 and LL.R4. Then if Ha sends a datagram to Hd: (1) Datagram 1: Ha -> R2 -> R4 -> Hd (2) XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha (3) Datagram 2: Ha -> R4 -> Hd Braden, Postel, Rekhter Expires: April 1994 [Page 10] Internet Draft Shared Media IP Architecture October 1993 (4) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha (5) Datagram 3: Ha -> Hd Note that we require the routing protocol to handle only per- network information, not per-host information. This results in the two-step redirection shown in this example. There are three aspects to the routing protocol modification. (1) The ability to pass "third-party" information -- a router should be able to specify the address (IP address and perhaps LL address) of some other router as the next-hop. (2) Knowledge of the "SameSM" attribute for routes. (3) The LL addresses corresponding to IP addresses of routers within the same SM. A router must be able to determine that a particular IP address (e.g., the source address) is in the same SM. There are several possible ways to make this information available to a router in the SM. (1) A router may use a single physical interface to an SM; this implies that all its logical interfaces lie within the same SM. (3) There might be some administrative structure in the IP addresses, e.g., all IP addresses within a particular national SM might have a common prefix string. (3) There might be configuration information, either local to the router or available from some centralized server (e.g, the DNS). Note that a router could consult this server in the background while continuing to forward datagrams without delay. The only consequence of a delay in obtaining the "Same SM" information would be some unnecessary (but temporary) hops. 4.3 Extended Proxy ARP The approach of Heinanen [Heinanen93] was intended to solve the problem of address resolution in a shared medium with no broadcast mechanism ("Non-Broadcast, MultiAccess" or NBMA). Imagine that the shared medium has a single IP network number, i.e., it is one network "cloud". He envisions a set of AR Servers within this Braden, Postel, Rekhter Expires: April 1994 [Page 11] Internet Draft Shared Media IP Architecture October 1993 medium. These AR Servers run some routing protocol among themselves. A source host issues an ARP Request (via a point-to- point LL transmission) to an AR Server with which it is associated. This ARP Request is forwarded hop-by-hop at the link layer, through the AR Servers towards the AR Server that is associated with the destination host. That AR Server resolves the address (using information learned from either host advertisement or a configuration file), and returns an ARP Reply back through the AR Servers to the source host. Ha Hb Hc Hd | | | | ---- | ---------- | ---------- | ---------- | ---- ( ) ( Shared Medium (One Logical Network) ) ( ) ----|--|---------|------------|----------|----|--- | | | | | | - R1 - | | | | --- R5 --- ____|__ __|____ __|____ _|_____ | AR Sa | | AR Sb | | AR Sc | | AR Sd | |_______| |_______| |_______| |_______| Figure 3. Single-Cloud Shared Medium Figure 3 suggests that each of the hosts Ha, ... Hd is associated with a corresponding AR Server "AR Sa", ..."AR Sd". This same scheme could be applied to the LIS model of Figure 2. The AR Servers would be implemented in the routers, and if the medium supports broadcast then the hosts would be configured for proxy ARP. That is, the host would be told that all destinations are local, so it will always issue an ARP request for the final destination. The set of AR Servers would resolve this request. Since routing loops are a constant possibility, Heinanen's proposal includes the addition of a hop count to ARP requests and replies. Like all proxy ARP schemes, this one has a seductive simplicity. However, solving the SM problem at the LL has several costs. It requires a complete round-trip time before the first datagram can flow. It requires a hop count in the ARP packet. This seems like a tip-off that the link layer is not the most appropriate place to solve the SM problem in general. Braden, Postel, Rekhter Expires: April 1994 [Page 12] Internet Draft Shared Media IP Architecture October 1993 4.4 Routing Query Messages This scheme [Halpern93] introduces a new IP level mechanism: SM routing query and reply messages. These messages are forwarded as IP datagrams hop-by-hop in the direction of the destination address. The exit router can return a reply, again hop-by-hop, that finally reaches the source host as an XRedirect. It would also be possible (but not necessary) to modify hosts to initiate these queries. The query/reply pair is supplying the same information that we would add to routing protocols under Extended Routing. However, the Query/Reply messages would allow us to keep the current routing protocols unchanged, and would also provide the extra information only for the routes that are actually needed, thus reducing the routing overhead. Note that the Query/Reply sequence can happen in parallel with forwarding the initial datagram hop- by-hop, so it does not add an extra round-trip delay. 5. Security Considerations We should discuss the security issues raised by our suggested changes. We should note that we are not talking about "real" security here; real Internet security will require cryptographic techniques on an end-to-end basis. However, it should not be easy to subvert the basic delivery mechanism of IP to cause datagrams to flow to unexpected places. With this understanding, the security problems arise in two places: the ICMP Redirect messages and the ARP replies. * ICMP Redirect Security We may reasonably require that the routers be secure. They are generally under centralized administrative control, and we may assume that the routing protocols will contain sufficient authentication mechanisms (even if it is not currently true). Therefore, a host will reasonably be able to trust a Redirect that comes from a router. However, it will NOT be reasonable for a host to trust another host. Suppose that the target host in the examples of Section 4.1 is untrustworthy; there is no way to prevent its issuing a new Redirect to some other destination, anywhere in the Internet. On the other hand, this exposure is no worse than it was; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere. Braden, Postel, Rekhter Expires: April 1994 [Page 13] Internet Draft Shared Media IP Architecture October 1993 * ARP Security Currently, an ARP Reply can come only from the local network, and a physically isolated network can be administrative secured from subversion of ARP. However, an ARP Reply can come from anywhere within the SM, and an evil-doer can use this fact to divert the traffic flow from any host within the SM [Bellovin89]. The XRedirect closes this security hole. Validating the XRedirect (as coming from the node to which the last datagram was sent) will also validate the LL address. Another approach is to validate the source address from which the ARP Reply was received (assuming the link layer protocol carries the source address and the driver supplies it). An acceptable ARP reply for destination IP address D can only come from LL address x, where the routing cache maps D -> E and the ARP cache gives x as the translation of E. This validation, involving both routing and ARP caches, might be ugly to implement in a strictly-layered implementation. It would be natural if layering were already violated by combining the ARP cache and routing cache. It is possible for the link layer to have security mechanisms that could interfere with IP-layer connectivity. In particular, there could possible be non-transitivity of logical interconnection within a shared medium. In particular, some large public data networks may include configuration options that could allow Net A to talk to Net B and Net B to talk to Net C, but prevent A from talking directly to C. In this case, the routing protocols have to be sophisticated enough to handle such anomalies. 6. CONCLUSIONS We have outlined four possible extensions to the Internet architecture to allow hop-efficient forwarding of IP datagrams within shared media. The changes to hosts are minimal (indeed, some hosts may require no changes at all). The changes to routers are more extensive, but can be introduced gradually. Our suggested extensions do not change the overall structure of the Internet architecture. It would be possible to make (and some have suggested) much more radical changes to accommodate shared media. In the extreme, one could entirely abolish the inner clouds in Figure 2, so that there would be no logical network structure within the SM. The IP addresses would then be logical, and some mechanism of distributed servers would be needed to find routes within this random Braden, Postel, Rekhter Expires: April 1994 [Page 14] Internet Draft Shared Media IP Architecture October 1993 haze. We think that throwing out what has been proven to work, and work well, might make a good research paper but would not be good Internet design strategy. 7. ACKNOWLEDGMENTS We are grateful to Keith McGloghrie, Joel Halpern, and others who rubbed our noses in this problem. We are also grateful to Gerri Gilliland who supplied the paper tablecloth, colored crayons, and fine food that allowed these ideas to be assembled initially. 8. REFERENCES [Bellovin89] Bellovin, S. M., "Security Problems in the TCP/IP Protocol Suite". ACM CCR, v. 19. no. 2, April 1989. [Garrett93] Garrett, J., Hagan, J. and J. Wong, "Directed ARP", RFC-1433, March 1993. [Plummer82] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982. [Halpern93] Halpern, J., Private communication, July 1993. [Heinanen93] Heinanen, J., "NBMA Address Resolution Protocol (NBMA ARP)", Work in Progress, June 1993. [Laubach93] Laubach, M., "Classical IP and ARP over ATM", work in progress, July 1993. [Postel81a] Postel, J., "Internet Protocol", RFC-791, September 1981. [Postel81b] Postel, J., "Internet Control Message Protocol", RFC-792, September 1981. [PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet Protocol". Computer Networks 5, pp 261-271, 1983. [RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", RFC-1122, October 1989. Security Considerations See Section 5 of this memo. Braden, Postel, Rekhter Expires: April 1994 [Page 15] Internet Draft Shared Media IP Architecture October 1993 Authors' Addresses Bob Braden University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (213) 822-1511 EMail: Braden@ISI.EDU Jon Postel University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (213) 822-1511 EMail: Postel@ISI.EDU Yakov Rekhter Office 32-017 T.J. Watson Research Center, IBM Corp. P.O. Box 218, Yorktown Heights, NY 10598 Phone: (914) 945-3896 EMail: Yakov@WATSON.IBM.COM Braden, Postel, Rekhter Expires: April 1994 [Page 16]